Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/972

Internet Message Format | 1994-08-27 | 11KB

Date: Fri, 22 Jul 1994 13:46:57 -0400 (EDT)
Date: Fri, 22 Jul 94 01:28 EST
Subject: Gem List (Please Post!) (fwd)
Subject: Gem List (Please Post!)
Subject:  winlib...
Subject:  Re: Gem List (fwd)
Date: Fri, 22 Jul 1994 13:46:57 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Fri Jul 22 02:31:05 1994
Date: Fri, 22 Jul 94 01:28 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: Gem List (Please Post!)
Message-Id: <33940722062833/[e-mail]>

Michael:
--------
> The reason I mentioned the keyboard is because the user will expect output
> to go to the top window when typing.  This has been a key aspect of
> GEM forever, and the user will expect it to hold true.  If there is
> not top window, or output goes to a window that is not topped, that
> is a confusing behaviour.  Perhaps XWindows handles this nicely, but
> it -started- that way.  Changing now would confuse the user
> needlessly.

What has this got to do with anything? WinLIB PRO always has the keyboard
focus on the topped window. To do otherwise is confusing. I don't know why
you brought this up, since WinLIB PRO doesn't do that.

> >GEM is not going to change to match my philosophy; so we're writing a
> >GEM Library to *match* the philosophy. There is no reason why users have
> >to be stuck in the dark ages in terms of a user interface.
> I'm not sure I understand your emphasis?  Match -what-?  The GEM
> philosophy (topped windows and all the other stuff you hate but is
> standard) or your own philosophy?  Coud you be more clear on this.

My philosophy : I want a *consistent*, *intuitive*, *easy to use*, *easy to
program* GUI that is powerful and fast. Currently GEM is *none* of these.

"Normal" GEM is inconsistent, non-intuitive, tricky to use, and more
difficult than it needs to be to program (AES 4.0 doesn't help anything).

WinLIB fixes all of these problems in one go.

Clear enough?

> > That is exactly the kind of thing I hate, auto-window-topping. If you had
> > actually read my message, you would have realized that.
> I did read your message, and I thought that this was a nice suggestion.
> If you do not want to top windows yourself, why not let the system do
> it so that you do not have to deal with it?  From the way you speak, this
> offends you to the core of your being...  :)

The problem here is that *I* want to be in control of the GUI, not let the
GUI control me. Therefore, I want to decide when windows get topped. And if
I want to access gadgets without having to top a window, I don't want to be
forced to use a *non-intuitive* method to access those gadgets (i.e. the
stupid left+right button combo).

> > It's confusing in that it's a non-consistent GUI design. There is no
> > reason why programmers have to be content with atari's stupid mistakes.
> There is one reason; the user expects it.  Small changes that improve the
> design are fine, of course, but major changes that shatter the old
> design are not fine.

It always makes me wonder why people are content living in the dark ages.

> > Other than the idiotic design in AES 4.x for hierarchical menus.
> I was talking about the menu layout, not the method of building a
> hierarchical menu.  I haven't honestly looked at that.

Look at it, and you'll find you will never look at AES 4.x quite the same
way again. :-)

> > We *did* do it right. If you had a copy of the demo program and used it,
> > you would never be able to tell that we do these so-called "time
> > wasting" things, unless we told you.
> Okay, Ken.  _Send_ me a copy, if you are willing, and I will look at it
> and summarize the experience to the list.  Does this sound fair?  I'll
> look at it objectively and tell you what I think.  This is about the
> tenth time you've said to someone that if they had only seen the
> demo copy they would be Might[ily] Impressed.  Well, if you were honestly
> offering, then send me a copy to [e-mail]
> and I will look at it and (maybe) be Might Impressed.

Actually, we *did* upload to the conference, but Yat declined to post it on
the basis that 'not everyone can use uudecode/unzip'. Shallow excuse
especially when other binaries have been posted to this conference in
exactly the same method.

I'm amazed at how much your attitude towards me has changed over the last
year.  Since we've not talked to each other since I sent you the last version
of WinLIB PRO, you've all-of-the-sudden got sour towards me.  Although I
don't take this personally, this is rather interesting when it comes toward
a person who was highly praising my library on ForemNET a year ago...  If
you keep talking down about it, why would you even WANT a copy of the
library?  I'll go ahead and send it to you anyway.

> > Wrong. Our library is much *smaller* than Gem++, yet has many more
> > features. The resulting executables that do the *same thing* as the
> > equivalent Gem++ program are generally several times *smaller*, not to
> > mention *faster*.
> GEM++ is a mega-library, though.  Of course it is big.  As for the size
> and speed, consider that you are using Pure C and GEM++ uses the
> monster-compiler C++.  How big is your library compared to EGEM, or
> SGEM, or ForceGEM?  Those are the biggest libraries I can think of
> for Pure C.  How does your library fit in with these?  (What is the
> actual SIZE of your library, for example?)

The size of WinLIB PRO (the old version) is 159,744 bytes (and this is
assuming that you will use *everything* in the library). WinLIB PRO
obviously strives for efficiency not simply in code size, but speed and
simplicity as well.

XAES (the reworked version of WinLIB PRO) is 238,592 bytes. Remember
of course that only the parts of the library that you use get linked into
your executable.

Tell me, where can I get SGEM, or ForceGEM?  What FTP sites, since I've never
heard of or seen these libraries.

> > Maybe you'll become confused by a straighforward GUI design, but I think
> > you'll be just about the only one. :-) Changing the mouse button
> > requirements for selection of a topped dialog and a background dialog are
> > totally against a sane GUI design. But then again, nobody ever claimed
> > atari is sane :-)
> Er, what?  I never said you should have to push a different button to use
> a background window.  I like the way Atari does it with MultiTOS, where
> you can use the left mouse button to operate the gadgets of a background
> window.

Notice the *key word* here. >>DIALOG<<, not >>WINDOW<<. So, it's o.k. to
operate background window gadgets with the left mouse button but it's not
o.k. to use the same button by itself for background dialog buttons? Talk
about inconsistent! :-)

>Yet you criticize us for improving on the wheel. Where do you draw the line?
> I draw the line at the point where you start changing the GUI so completely
> that a casual GEM-user would be confused by your changes.  Programs that
> are hard to learn do not get used, unless they are really, really great
> programs.

WinLIB PRO is easy to use, as the extended functionality is simply intuitive
extensions of what the user already knows. Unlike some of atari's
'extended features' which are decidedly non-intuitive. WinLIB strives to have
a CONSISTENT, INTUITIVE user interface, whereas 'other' people seem to strive
for exactly the opposite :-)

There are no major changes that would confuse the user, ie. with the custom
windows, the settings are the same (albeit there are other settings like
OPTIONS, ICONIFY, and CASCADE.)  There is nothing different about handling
the windows, just that you have to use my custom routines (WWindGet and
WWindSet.)  In the source I'm sending you, you'll see this.

> > WinLIB PRO was designed after intensive study of over *20* GUI libraries.
> > It incorporates the best ideas of all of them (we steal from the best, and
> > forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
> > easy to use. WinLIB PRO does most of the work for you, with an extremely
> > straightforward, simple API.
> If you send a copy of the demo program to me, I'll be more than happy
>